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ABSTRACT 

Level Zero Processing (LZP) generally refers to telemetry data processing functions performed at ground 
facilities to remove all communication artifacts from instrument data. These functions typically include frame 
synchronization, error detection and correction, packet reassembly and sorting, playback reversal, merging, 
time-ordering, overlap deletion, and production of annotated data sets. The Data Systems Technologies Division 
(DSTD) at Goddard Space Flight Center (GSFC) has been developing high-performance Very Large Scale 
Integration Level Zero Processing Systems (VLSI LZPS) since 1989. The first VLSI LZPS prototype demonstrated 
20 Megabits per second (Mbps) capability in 1992. With a new generation of high-density Application-specific 
Integrated Circuits (ASIC) and a Mass Storage System (MSS) based on the High-performance Parallel Peripheral 
Interface (HiPPI), a second prototype has been built that achieves full 50 Mbps performance. This paper 
describes the second generation LZPS prototype based upon VLSI technologies. 


1. INTRODUCTION 

With the new Earth Observing System (EOS) era of satellites, telemetry downlink data rates will 
increase to 50 Mbps and beyond. Currently, most NASA missions operate at rates under 1 Mbps. 
These low data rates allowed ground system designers to use mainframes as well as workstation 
class computers to handle all the LZP with software, in near real-time. The ground system 
designers had little need to investigate hardware approaches to LZP. 

The DSTD at GSFC saw the need for future high-rate ground telemetry systems, as well as the 
drawbacks to a full software implementations and began investigating VLSI technologies and their 
application to telemetry processing in 1989. The completion of the Consultative Committee for 
Space Data Systems (CCSDS) data format recommendations [l][2], made a combined 
hard ware/ soft ware approach for performing LZP feasible. The hardware could be designed to 
understand the CCSDS data format and allow software to intervene for error condition handling or 
to handle non-standard data formats. The DSTD chose to implement a standard set of 2.0 Micron 
VLSI CMOS technology devices that would provide correlation, frame synchronization, frame 
buffering, packet sorting, and Central Processing Unit (CPU) support; all derived from the 
CCSDS recommendations. Using this set of VLSI components, the DSTD was able to build a set 
of processing modules based on the Versa Module Eurocard bus (VMEbus). Each processing 
module was responsible for one stage of telemetry processing, for example: frame 
synchronization, Reed-Solomon error detection and correction, or packet processing. With the use 
of these modules, the first VLSI LZP system prototype demonstrated sustained data rates up to 20 
Mbps in the summer of 1992 [3]. 

The success of this prototype and the high data rate requirement from the Fast Auroral Snapshot 
Explorer (FAST) mission led to the development of FAST Packet Processing System (PPS). To 



FAGS BLANK NOT FILMS® 


105 




support high-resolution observation inside the auroral acceleration zone, the FAST satellite 
telemetry features downlink data rates up to 2.25 Mbps and data volume of 3.6 Gbytes per dav. 
The project scientists also require all instrument data level zero processed and delivered within two 
hours of spacecraft downlink for their near real-time experiment. To meet these challenges the 

LZPS pr °i° type was chosen for science data processing. Within 15 months, 
. -fr,c AST Packet Processing System (PPS) was developed and delivered based on the VLSI 
LZPS prototype to support the FAST mission [4], 

To continue the efforts of applying VLSI ASIC technologies to telemetry processing, the DSTD 
has migrated the original designs to new 0.6 and 0.8 micron ASICs capable of supporting data 
rates up to 300 Mbps. These new ASICs have been incorporated into a new set of processing 

mte S ratl °n. Using these new modules, and some Commercial Off-the 
t vdc boar ds, the DSTD has been able to design a second generation VLSI LZPS (VLSI 

LZPS 2) capable of 50 Mbps performance. This paper discusses the general architecture and 
functionality ot the VLSI LZPS-2, with emphasis on the new elements and features, including an 
automated operations environment based on object-oriented design. Potential applications of this 
prototype in NASA s current and future missions are discussed as well. 

2. SYSTEM FUNCTIONAL REQUIREMENTS 

As a successor to the VLSI LZPS prototype phase 1 (VLSI LZPS-1), the VLSI LZPS-2 has not 
only continued to provide the functions implemented in VLSI LZPS-1, but has also added many 

® ™ j ° r perf ° rmance breakthrough is the boost of sustained processing rate 
trom 20 to 50 Mbps. The major functional enhancement is the support for CCSDS Advanced 
Orbiting System (AOS) data formats in addition to the packet telemetry formats. Services have 
been expanded from just Path service to others, including Virtual Channel Access (VCA) Virtual 
Channel Data Unit (VCDU), Bitstream, and Insert services. 

I 1 ' 1 ® VL ^ I r ZPS : 2 Wl11 provide three types of data products: real-time data, quicklook data sets, 
and production data sets. The real-time data includes source packets received from selected 
instruments and data extracted from the insert zone, if desired. The data will be delivered to the 
users as soon as it is received. The quicklook data sets are generated for selected instruments 
hach quicklook data set contains all packets received from an instrument in the order they were 
received. The production data sets are generated for all instruments, and may include data received 
trom one or more passes or sessions. Packets in the production data sets are forward-time- 
ordered, with redundant ones removed from overlap regions. Data quality is checked; errors and 
gaps are annotated as a part of the data set. 

Data distribution will be performed through standard networks such as Ethernet and Fiber 

Prn ^ bU m d L ° ata * nterface ( FDDI X an ^ standard protocols such as Transmission Control 
Protocol/Intemet Protocol (TCP/IP) and File Transfer Protocol (FTP). With this suite of 

real_time packets and production data sets can be sent to users directly from the VLSI 
LZPS-2 to simplify user interface and system operations. The processing latency is less than 5 ms 
for real-time data and 3 hours for production data sets. 

In order to reduce operational staffing level and cost, the VLSI LZPS-2 emphasizes an automated 
operation environment. This environment will be able to setup system support automatically 
based on a master schedule. It will also allow users to locally or remotely setup and control 
system operations and monitor telemetry processing status. System events will be displayed, 
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annotated, and logged. Quality and accounting reports will be generated and logged for each 
processing session. The user interface will be graphically based and all commands will be menu- 
driven. 

3. VLSI LZPS-2 SYSTEM ARCHITECTURE 

The VLSI LZPS-2 is built upon the existing architecture of the 20 Mbps VLSI LZPS-1. This 
architecture emphasizes the utilization of VLSI technologies and industry standards. Over the past 
8 years, the DSTD has developed a set of VLSI ASIC chips that perform standard telemetry 
processing functions. These chips are integrated into a set of custom-designed, highly reusable 
cards based on the industry standard VMEbus. Each card performs one or more generic telemetry 
processing functions. Through the high-level integration of these common telemetry processing 
functions into VLSI chips and cards, the system achieves high-performance, high reliability, low 
maintenance and cost. 

To integrate these custom cards together with COTS VMEbus components into telemetry data 
processing systems, a modular software package has been developed that provides a generic 
software platform. With this platform, a system designer can select and configure a system based 
on various VMEbus processing cards depending on the given system processing requirements. 
Thus, the system based on this architecture offers high-configurability, reusability, and 
upgradability. 

Automated operation is emphasized throughout the system design at all levels. The design of the 
VLSI LZPS ensures that all operations can be controlled by a remote host such as a Control 
Workstation, and that all status required for monitoring operations be collected and reported to the 
remote host. Once initialized for a pass, the VLSI LZPS requires no remote intervention to 
process data. The system will continue to operate even if the remote host fails during a pass. 

The VLSI LZPS-2 rack, shown in Figure 1, contains a 21 slot VMEbus system, a 40 Gbytes 
super disk array system (super disk farm), and dual power supplies. The super disk farm takes up 
1-1/4 standard 19 inch 6 foot racks. The remaining space in the second rack is used to house the 
VLSI LZPS VME Processing System. Figure 2 illustrates the system block diagram of the 
second generation VLSI LZPS, which contains four subsystems: the Control and Communication 
Subsystem (CCS), Frame Processing Subsystem (FPS), Data Set Processing Subsystem (DSPS) 
and MSS. 

Each CPU within the rack runs its own copy of the VxWorks operating system. This is a UNIX 
like real time operating system that supports Network File System (NFS) protocols as well as 
FTP. Source code is developed and compiled on a separate platform, such as a SUN workstation 
and loaded dynamically across the network during operation. This seamless integration of a 
development platform and its application target provides a powerful real-time software 
development environment. 

The CCS provides system base functions, including command and control, network interfacing, 
and system data storage. The FPS receives serial telemetry data, performs standard frame 
processing functions, and outputs synchronized frames to the DSPS. The DSPS extracts source 
packets out of the frames and delivers packets from each specified source to the user in real-time. 

It sorts all packets by source, merges real-time and playback data into data sets, and removes 
redundant data from the data sets. The output of the DSPS is quality annotated data sets. The 


107 



MSS serves as a large data buffer for data set processing and rate buffering. The detailed design of 
each subsystem is given in the following sections. 



4. VLSI LZPS-2 SUBSYSTEM DESIGN 


The VLSI LZPS-2 functional block diagram is depicted in Figure 2, which shows a set of 
commercial and custom-designed processing modules integrated in the VMEbus environment 
™f h S ® modules are grouped into the CCS, FPS, and DSPS subsystems, with the disk farm being 
m the MSS. The VMEbus is used for transferring command and status information among the 
modules It is also used for high-performance 32-bit and 64-bit block data transfers to store and 
retrieve data to and from the MSS. High-speed telemetry data is transferred from one module to 
the other through the VME Subsystem Bus (VSB) and the custom telemetry pipeline 

implemented on the J3 backplane. Each subsystem will be described in detail in the following 
sections. 


4.1 THE CONTROL AND COMMUNICATION SUBSYSTEM 

The CCS consists of a Master Controller card, a FDDI Interface Processor, a Time Code 
Processor card, a 128 Mbytes Dynamic Random Access Memory (DRAM) buffer two 16 

baC A^ U P St , atic RAM ( SRA M) cards, and a Small Computer Systems interface 
(SCSI) disk drive. All modules in the CCS are COTS products. 
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* Data Set Processing includes packet reassembly, sorting, playback 
reversal, forward time ordering, data merging and overlap deletion. 

* Phase II prototype handles 50 Mbps ingest rate, 15000 packets 
per second with data storage of 40 Gbytes. 

* Utilizes Code 521 developed Functional Component Approach. 
Supports Realtime, Quick Look, and Production Processing modes. 

' Handles 8 Spacecraft IDs, 32 virtual channels and 256 source iDs. 
Provides graphical user interface with automated operation capability 
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Figure 2. VLSI LZPS-2 Functional Block Diagram 





















The Master Controller is based on a commercial VMEbus single board computer. It provides 
support for the Ethernet network and for the system disk. Through the use of the Vx Works 
operating system, both the Ethernet and the system disk can be shared by all CPUs on the 
VMEbus. The Master Controller accepts commands and configuration parameters from a Control 
Workstation, interprets the commands, and sends appropriate subcommands to the other system 
modules. Based on the commands, it configures the system for processing sessions. The Master 
Controller also gathers housekeeping and processing status and reports them to a remote Control 
Workstation. If any processing statistics exceed user-specified thresholds, the Master Controller 
can send event messages to the Control Workstation to alarm the operator. All interfacing to the 
Control Workstation is done using standard TCP/IP sockets on the Ethernet network. 

The CCS provides interfaces to two networks: the Ethernet Local Area Network (LAN), and the 
FDDI LAN. The Ethernet interface is used for transferring command and status between the 
VLSI LZPS-2 and the Control Workstation. It may also be used for transferring real-time packets 
from the VLSI LZPS-2 directly to the user during real-time processing. 

The FDDI LAN links the VLSI LZPS-2 directly to the user. Real-time packets can be sent out to 
the FDDI LAN during real-time processing. All production data sets are sent to the user via the 
FDDI LAN. As with the Ethernet, full TCP/IP support is provided for all data going out the 
FDDI port. The VLSI LZPS-2 will send each data set using FTP to designated users according to 
an operator-defined distribution table. This is a new feature that eliminates the need for an 
additional system to handle data distribution. 

The 32 Mbytes of battery backed up SRAM serve as non-volatile ram disks used for maintaining a 
system database for high-speed access. The Time Code Processor inputs NASA36 time code and 
provides the current time to the FPS for time stamping of incoming frames. The 128 Mbytes 
DRAM buffer serves two purposes. During data set outputting, it provides rate buffering between 
the DSP and the FDDI network interface. The second use is during internal system testing. Test 
data is processed by the VLSI LZPS, and data sets are placed in the buffer memory for error 
checking. This allows the system to perform a full internal self test without extra equipment. 

4.2 THE FRAME PROCESSING SUBSYSTEM 

The FPS consists of a High-rate Frame Synchronizer (HRFS) card and a Reed-Solomon Decoder 
(RSD) card designed and built by the DSTD. Their functions are illustrated in Figure 3, together 
with modules from the DSPS. 

The HRFS performs the frame synchronization functions. It receives serial telemetry data and 
clock through either a RS-422 interface, or a I00K Emitter Coupled Logic (ECL) interface. The 
card synchronizes the serial data to transfer frames according to a specified synchronization pattern 
and strategy. The card checks for Cyclic Redundancy Check (CRC) errors on each frame, if 
desired, and all results are reported in a quality trailer appended to each frame. 

The RSD performs Reed-Solomon error detection and correction on the frame headers and frame 
data. The card is capable of 255-223 decoding on the frames and 10-6 decoding on the frame 
headers with interleaves 1 through 5. The results of all the error detection and correction are 
appended to each frame in a second quality trailer as it is sent the DSPS subsystem. The operator 
specifies the type of decoding desired and the filtering options for the RSD. A bypass option is 
provided for non-Reed Solomon encoded frames as well. 
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The DSPS consists of a Service Processor, a Data Set Processor, an Annotation Processor, a 128 
Mbytes Data Record Buffer, and two SCSI disk drives. The Annotation Processor, Data Set 
Processor motherboard, and the Data Record Buffer are all COTS VMEbus products. The 
Service Processor and a mezzanine on the Data Set Processor are custom-designed and built by the 
DSTD and described in References 5 and 6. Their operations are also illustrated in Figure 3. 

The Service Processor receives transfer frames from the RSD. It extracts packet data pieces from 
the frames, reassembles source packets, checks packet errors, and generates annotation for each 
packet. During a pass, packets from specified sources as specified by spacecraft ID, Virtual 
Channel Identifier (VCID), and Application Process Identifier (APID) are output to the user 
through the CCS as soon as they are received. The Service Processor also sorts packets by source 
and groups them into data records while outputting them to the Data Record Buffer (DRB) on the 
VSB. Packet time code is extracted, and sent to the Annotation Processor (AP) together with 
packet quality information as annotation data for storage in the annotation disks. Whenever a 
record is full, the Data Set Processor moves packets from the record buffer to the data disk 
through the VMEbus using the VME64 protocol. 

When the pass is over, the AP examines the annotation data of each sensor, which consists of one 
or more sources, to determine how to merge real-time and playback data into a production data set, 
how to forward-time-order the packets, and where the overlap boundaries and redundant packets 
are. The result of this analysis will be stored in a data set assembly table file which will serve as an 
instruction set for assembling a data set. In addition to the assembly instruction sets, the AP 
generates quality annotation for each data set. The quality annotation indicates which packets have 
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errors and type of errors; for example: the packet came from a frame with CRC errors. The 
quality annotation also indicates the locations and sizes of gaps in the data set. 

The Data Set Processor can begin output processing once each data set assembly file is finished by 

u Vfcc The Data Set Processor reads the assembly file, and begins retrieving data records from 
the MSS. The data records are received on the DSP from the HiPPI port, and locally Direct 
Memory Access (DMA) transferred to the Data Reassembly Unit Mezzanine (DRUM) for 
reassembly. The DRUM is a custom designed card by the DSTD and contains the Enhanced Ram 
Controller (ERC) ASIC also developed by the DSTD [7][8]. The ERC provides 4 Mbytes of data 
storage, with flexible output formatting based on instructions loaded into the chip. Once the ERC 
buffer is loaded, the DSP begins outputting the data sets from the DRUM, and DMAs the data to 
the FDDI interface using VME 32-bit block transfers. The FDDI interface then transfers the data 
using FTP to the user. This operation is repeated until the entire data set is output. The DSP then 
waits for the next assembly file from the AP. This direct FTP from the VLSI LZPS eliminates the 
need for another system to handle the data set transfer and maximizes the utilization of the MSS by 
using it as a short-term data storage device, not just a rate buffering device. The use of the DRUM 

^ nd ^ PPI 0 card reduces the thf ee 9u VME cards in the DSP subsystem of the first generation 
VLSI LZPS to one 6u card in the second generation system. 

4.4 THE MASS STORAGE SUBSYSTEM 

In telemetry level zero processing, data merging and overlap deletion functions can only be 
accomplished after all data has been received. Therefore, the VLSI LZPS system needs to store 
enough data to meet the users requirements for data set size. In addition to accumulated storage, 
rate buffering is required between the telemetry input and data set output. This data storage and 
rate buffering capability is provided by the MSS. 

The MSS employs a Maximum Strategy HiPPI Super Disk Array system (super disk farm) with 

i° oT 6S 0f dlsk space ’ conf >g urable up to 320 Gbytes. This system is an enhanced version of 
Sp 2 unit used in the first generation of VLSI LZPS. The SP2 model is a single unit capable of 
160 Mbps data transfers and 10 Gbytes of data storage. The Super Disk Farm uses four SP2 
units, and is capable of 640 Mbps continuous data transfers and 320 Gbytes of redundant storage. 
The super disk farm contains a super controller with a HiPPI interface and four custom ports to 
interface to SP2 disk farms. The super controller stripes the data across 4 of the SP2 units which 
in turns stripes the data across 8 disks with parity. This dual-level striping allows the super disk 
farm to operate at the full 640 Mbps continuous ingest rate. The DSPS interfaces to the super 
controller through the HiPPI network interface. This link is capable of 800 Mbps burst data 
transfers. Due to the DSP VMEbus interface, the maximum data transfer rate achievable is 408 
Mbps from the Data Record Buffer to disk. This transfer speed far surpasses the system 
requirements of 50 Mbps and ensures maximum available bandwidth on the VMEbus for other 
operations. Information concerning the speed evaluation of the VMEbus to HiPPI to Disk farm 
link are available in reference 9. 

Data integrity is an absolute must in an operations environment where serial data retransmission is 
™ ;mposs ible , extremely difficult, or very expensive. This fact imposes the requirement on the 
VLSI LZPS that the MSS will function normally, without interruption or data loss, even if disk 
drives fail within the subsystem. The Strategy HiPPI Super Disk Farm achieves true fault tolerant 
operations with the use of a 48-bit Error Correction Code (ECC), parity disk drive, and stand-by 
disk drive on each SP2 unit; there are four SP2 units in the system. To further expand the fault 
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tolerance, additional SP2 units can be added to the Supper Controller to provide a second layer of 
Parity and Standby Disk Farms. With this scheme of ECC and parity protection, the Super Disk 
Farm can operate at full speed even if a disk drive is lost. Data integrity is preserved by the parity 
drives that can be used to reconstruct data that was on a lost drive. The drives are hot-swapable, 
and reconstruction is transparent, meaning it can be accomplished while data transfers are being 
performed. te 

5. AUTOMATED OPERATIONS ENVIRONMENT 

One major goal of the whole VLSI LZPS development project was to provide fully automated 
operations of the system, from activity scheduling and remote setup to status gathering and data 
distribution. To accomplish this goal, the DSTD developed a UNIX-based software package 
called Telemetry Processing Control Environment (TPCE) [10]. The role of TPCE is to provide a 
Graphical User Interface (GUI) to make configuring and gathering status from the VLSI LZPS 
more user friendly. The system accepts an activity schedule from a file or network socket. TPCE 
will automatically initiate telemetry processing based upon activities identified in the schedule and 
can be edited by the local operator if necessary. Each activity in the schedule is associated with a 
pre-defined configuration set which is used for processing that particular telemetry session. 
Through the use of configuration sets, the VLSI LZPS/TPCE combination can support various 
types of telemetry processing scenarios. TPCE also provides the capability to edit all configuration 
sets. Data set distribution by the VLSI LZPS is also managed by TPCE. A log is kept of all data 
sets output, and any retransmission of individual data sets by user request. TPCE provides the 
link between the operator/user of the VLSI LZPS and the hardware, there-by keeping the user 
interface consistent, even after hardware upgrades. 

6. POTENTIAL APPLICATIONS 

The second generation VLSI LZPS is developed in anticipation of demands for high rate ground 
data processing systems in the 1990's and beyond. The selection of functional and performance 
specifications for the prototype has closely followed the requirement development of NASA's 
major missions such as Earth Observing System (EOS), Space Station, and Landsat-7. As a 
compact CCSDS telemetry processing system, the VLSI LZPS-2 can be used in many 
applications, including science data processing at permanent sites and at transportable ground 
stations, spacecraft Integration and Test, and ground data system testing and verification. Its 
modular architecture allows it to be configured as a stand alone system, or as a core processor in a 
large scale ground data system. Based on the FAST PPS development experience, the prototype 
system can be converted into a full production system in about 10-12 months. 

7. SUMMARY 

The design of the second generation VLSI LZPS has been discussed with the implementation of 
the particular subsystems covered in detail. Based on functional components and VLSI 
technologies, the VLSI LZPS supports CCSDS version 2 data processing at rates up to 50 Mbps 
with real-time and near real-time science data processing and fully automated data distribution. 
With the addition of a UNIX workstation, fully automated operation is achieved with the TPCE 
system. The fully automated operation allows projects to reduce operational staffing as well as 
operational costs. Because of extensive use of VLSI components and modular design, the system 
renders compact size, high reliability and high maintainability. The use of hardware and software 
functional components allows a full production system to be ready in less than a year. 
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9. NOMENCLATURE 


AOS 

AP 

APID 

ASIC 

CCSDS 

COTS 

CPU 

CRC 

DRAM 

DRUM 

DRB 

DSTD 

ECL 

EOS 

ERC 

FAST 

FDDI 

FPS 

FTP 

GSFC 

GUI 

HiPPI 

HRFS 

LAN 

LZP 

LZPS 

Mbps 

Mbytes 

MSS 

NFS 

RSD 

SCSI 

SRAM 

TCP/IP 

TPCE 

VCA 

VCDU 

VCID 

VMEbus 

VLSI 


Advanced Orbiting Systems 

Annotation Processor 

Application Process Identifier 

Application-specific Integrated Circuits 

Consultative Committee for Space Data Systems 

Commercial-Off-the-Shelf 

Central Processing Unit 

Cyclic Redundancy Check 

Dynamic Random Access Memory 

Data Reassembly Unit Mezzanine 

Data Record Buffer 

Data Systems Technology Division 

Emitter Coupled Logic 

Earth Observing System 

Enhanced Ram Controller 

Fast Auroral Snapshot Explorer 

Fiber Distributed Data Interface 

Frame Processing Subsystem 

File Transfer Protocol 

Goddard Space Flight Center 

Graphical User Interface 

High-performance Parallel Peripheral Interface 

High-rate Frame Synchronizer 

Local Area Network 

Level Zero Processing 

Level Zero Processing System 

Mega bits per second 

Megabytes 

Mass Storage Subsystem 
Network File System 
Reed-Solomon Decoder 
Small Computer Systems Interface 
Static RAM 

Transmission Control Protocol/Intemet Protocol 

Telemetry Processing Control Environment 

Virtual Channel Access 

Virtual Channel Data Unit 

Virtual Channel Identifier 

Versa Module Eurocard bus 

Very Large Scale Integration 


115 




A CORPORATE MEMORY FOR THE GSFC MISSION OPERATIONS 

DIVISION 


Beryl Hosack 
CSC/GSFC 


Paper Not Available 



117 

FAGS PLANK NOT FUMOO* 



